<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Guideline: Analyze the Design</title>
<meta name="uma.type" content="Guideline">
<meta name="uma.name" content="analyze_the_design">
<meta name="uma.presentationName" content="Analyze the Design">
<meta name="element_type" content="other">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="__MnggPTdEduDKIuqTXQ8SA"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Guideline: Analyze the Design</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/guidance.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This guideline describes how to approach creating a solution from requirements or change requests. A better solution will usually emerge when even a brief amount of time is spent analyzing the problem and considering approaches.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/tasks/design_solution_A97CE9EA.html" guid="_0fshwMlgEdmt3adZL5Dmdw">Design the Solution</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Evolve the Design</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><h1>
    Identification of elements
</h1>
<p>
    Identify the elements, based on the needs of the requirements. The identification of elements can stem from a static
    perspective of walking through the requirements and identifying elements clearly called out, which is a form of domain
    modeling. This can pull in other elements identified as being in the application domain or deemed necessary from
    examining the requirements for the portion of the system being designed. This identification can also pull from key
    abstractions identified while defining the architecture.
</p>
<p>
    The identification of elements should also apply a dynamic perspective by walking through scenarios of use of the
    system (or subsystem) and identifying elements needed to support the behavior. That behavior might be a scenario of use
    from an external user perspective or, while designing a subsystem, a responsibility assigned to the subsystem that has
    complex algorithmic behavior. Consider applying the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> to identify the elements necessary to support the
    scenario, or apply other patterns identified in the architecture that specify the elements that will be used to support
    specific aspects of the scenario.
</p>
<p>
    If you are designing a real-time system, include elements to represent events and signals that allow you to describe
    the asynchronous triggers of behavior to which the system must respond. <b>Events</b> are specifications of interesting
    occurrences in time and space that usually (if they are noteworthy) require some response from the system.
    <b>Signals</b> represent asynchronous mechanisms used to communicate certain types of events within the system.
</p>
<p>
    If there are existing elements from previous passes over the design or from selected frameworks or other reusable
    elements, reuse them whenever possible. See <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html" guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>.
</p>
<p>
    After identifying the elements, give each one meaningful name. Each element should also have a description, so that the
    team members who work together to refine the design and implement from the design will understand the role that each
    element plays.
</p>
<p>
    Based on this information, the identification of elements could be applied several times in designing just one part of
    the system. Although there is no one correct strategy for multiple passes, they could be done at a coarse-grained level
    and then a fine-grained level, or at an analysis (abstract) level and then a design level.
</p>
<h1>
    Behavior of elements
</h1>
<p>
    To identify the behavior of the elements, go through scenarios and assign behavior to the appropriate collaborating
    participants. If a particular use of the system or subsystem can have multiple possible outcomes or variant sequences,
    cover enough scenarios to ensure that the design is robust enough to support the possibilities.
</p>
<p>
    When assigning behavior to elements, consider applying the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;or other patterns identified in the
    architecture.
</p>
<p>
    Behavior can be represented as a simple statement of responsibility, or it can be a detailed operation specification.
    Use the appropriate level of detail to communicate important design decisions while giving the freedom to make
    appropriate implementation decisions as those tasks ensue.
</p>
<p>
    Avoid too much identification of behavior solely from the perspective of domain modeling. Include only behavior that is
    really needed -- behavior identified by going through required scenarios of system use.
</p>
<p>
    Behavior must be understood as a responsibility of an element, as well as an interaction between two elements in the
    context of some broader behavior of the system or subsystem. The latter part of this will lead the developer to
    identify relationships that are necessary between the elements.
</p>
<h1>
    Design element relationships
</h1>
<p>
    The relationships between the elements necessary for the behavior must be designed. This can simply be the
    identification of the ability to traverse from one element to another or else a need to manage an association between
    the elements. Relationships can be designed in more detail, as appropriate. This can include: optionality,
    multiplicity, whether the relationship is a simple dependency or managed association, and so on. These decisions that
    drive implementation details are best made at the design level, where it is easier to see how all of the pieces fit
    together.
</p>
<p>
    Avoid defining too many relationships based on relationships in the application domain. Include only relationships that
    are needed based on the requirements. On the other hand, a combination of requirements knowledge and domain knowledge
    can lead to some detailed decisions on the relationships, such as optionality and multiplicity.
</p>
<h1>
    Analysis classes and YAGNI
</h1>
<p>
    Analysis classes are used to identify initial buckets where system functionality should go. They're the first pass at
    understanding where system behavior will be realized in the design and implementation. For example, an entity class
    might initially represent all of the behavior for an employee, such as storing personal information and calculating the
    value of a paycheck. Few assumptions are made about how the final design will look at this point. Analysis classes are
    about making sure required behavior is represented somewhere in the system, rather than about creating a perfect
    design.
</p>
<p>
    Analysis classes allow you to begin designing from abstractions, so that the details of the system depend on those
    abstractions and not the other way around. In the Employee class, the notion of an employee should start with the idea
    of someone who works for the company, who has responsibilities and receives benefits. It's easier to create a design
    from this simple idea. The complexity of the design should emerge from the abstract ideas of what the design needs to
    do. This will also help keep coupling low and cohesion high.
</p>
<p>
    YAGNI (You Aren't Going to Need It) is an approach to design where the developer creates only enough implementation and
    design to address the required functionality. No assumptions are made about re-use or possible future uses of the
    software. Software is improved when the system requirements demand more functionality or robustness.
</p>
<p>
    The first classes created from a YAGNI perspective are much like analysis classes. You don't know how complex it may be
    to calculate a paycheck for your employee, so you assume that functionality is highly cohesive with the rest of what
    the Employee class must do. As you understanding of the requirement develops, the analysis class evolves into a set of
    collaborating classes and patterns that better support the behavior of the system. For example, payroll calculations
    could be moved into a pattern that handles all of the different types of paycheck calculations (overtime, commissions,
    and so forth), thereby increasing the internal cohesion of the class.
</p>
<p>
    Use analysis classes to define an initial place to put system behavior, and add only enough behavior to satisfy the
    YAGNI perspective. Analysis classes will evolve into concrete design classes as more behavior is added and as the
    design is refactored. See <a class="elementLinkWithType" href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a>.
</p></td>
</tr>
</table>
</div>
<div class="sectionHeading">More Information</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Checklists</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/checklists/design_68980812.html" guid="_0XSzsMlgEdmt3adZL5Dmdw">Design</a>
</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Concepts</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/concepts/design_E36137FA.html" guid="_bFjlAPTYEduDKIuqTXQ8SA">Design</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/concepts/requirements_realization_55C64ACB.html" guid="_T9FbYFRFEd2o7OqLaYh8nA">Requirements Realization</a>
</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Guidelines</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/designing_visually_BDE9A06A.html" guid="_1fM3AC9_EduW5uTjiIcspQ">Designing Visually</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Evolve the Design</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html" guid="_vO2uoO0OEduUpsu85bVhiQ">Software Reuse</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"><p> This program and the accompanying materials are made available under the<br />
  <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse 
  Public License V1.0</a>, which accompanies this distribution. </p><p/><p> <a class="elementLink" href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/openup_copyright_C3031062.html" guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a></p></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
